接下來的日子，Jerry不是在解決問題，就是在解決問題的路上。

此時開發部門的所有人，都認識這位手上拿著破筆電的網路工程師，遊走在不同網站業務的同仁身邊。

但讓Jerry最困擾的就是同仁都會問他一句話，以前都不會這樣啊~~不是問題的都變問題了!!

流量都只跑同某幾台主機

一日，Jerry接到某一個服務開發的電話，說自從CDN上線後，他準備的6台主機只有2-3台在忙，以前都不會。

Jerry聽完就詢問，你的負載均衡沒有設定抓真實IP調整分流的機制嗎?

開發回說，我的設備好像沒這個選項可以設定耶，還是你要幫我看?

當開發打開介面時，Jerry驚呆住!! 這不是一台防火牆嗎?

開發說明著，當初預算有限啦，廠商說這個設備有防火牆也能做負載均衡，用起來還ok啦!!

Jerry跟開發說明，這個設備無法導入憑證所以沒辦法看HTTP標頭，也就無法依據真實IP資訊進行分流了。

也慶幸這個服務多是API請求為主，交易請求不需要跟原先的主機進行請求。

因此，Jerry請開發找廠商來調整，設備上其他的負載均衡機制，看看能否將請求再更分散一點到其他主機，當然編列預算更換設備是更佳的作法。

沒有固定IP

某一個金流服務，在上線後客戶打來說無法連線，原因是IP變了?

Jerry意識到問題在哪裡，因為服務原本對外是ISP線路的固定IP，但導入CDN後就不再有固定的IP。

即便透過防火牆設備透過DNS解析到的IP，也會有快取的時間例如30分鐘。因此當CDN商全球負載均衡機制調整時，DNS解析出來的IP與防火牆查到IP快取不同，導致被阻擋。

開發好奇的問到，他發現廠商規模越大越容易有這問題，為何?

Jerry思考了一下猜測，也許是規模越大的公司網路安全機制上，就會限制伺服主機連到網際網路的目標IP，因此導入CDN後沒有固定IP就會有問題。

那該怎麼辦，Jerry提出兩種方式:

1. 在防火牆上，針對該主機的Internet存取設定為IP->ANY、 Port-> TCP/80 以及 TCP/443 Allow，然後在WEB Proxy上設定只能請求xxx.lekuza.com的url進行請求，其他一律禁止。

2. 請對方在DNS或是主機的Hosts上，設定服務的domain對應到固定IP，也就是不走CDN開例外。雖然這種方式失去當線路異常時，無法透過DNS機制切換線路，但可以透過偵測或是通知廠商改為另一條IP來存取，先讓服務會通就好。

請求逾時

一日下午，開發又打給Jerry，說客戶只要大筆資料請求的時候都會異常，現在在線上急著要處理。

Jerry立即打給顧問詢問該怎麼處理!!

顧問先是請Jerry問開發，這個請求的URL路徑以及Method為何，以及請求的過程?

開發說，這個功能是提供給合作廠商在線上查自己的訂單跟金額報表，資料量大時可能後端資料庫要跑個5分鐘以上，因為是報表功能所以Client網頁就會一直等結果。

顧問得知問題後，通知Jerry要調整一個叫做Read Timeout的設定。

Jerry問，為何?

因為當CDN主機遲遲未收到源站的回應時，就會將 504 閘道逾時錯誤傳回給用戶端。此時需要調整一個較長的時間，避免整個請求還沒結束，使用者端就收到異常。

不過Jerry這個設定要小心，要設定的標的務必是需要驗證登入的URL，否則萬一被攻擊主機的資源就會一直被占用喔!!

expect: 100-continue

某日下班前，Jerry接到開發部門電話，請他確認某一家廠商的IP有沒有被防護機制阻擋。

Jerry透過介面查詢並未發現有被阻擋的紀錄，但開發回覆說廠商有收到被阻擋的訊息。

於是Jerry只好設定條件紀錄廠商IP的所有請求，發現了一個讓他感到興趣的HTTP標頭 :expect: 100-continue。

在詢問顧問後才知道，這種請求方式會跟Akamai一個最佳化線路SureRoute機制相衝突!!

先來介紹SureRoute機制。

SureRoute 是 Akamai CDN的核心功能。它會測試 Akamai CDN伺服器與源站伺服器之間的多個路由，以識別效能的最佳路徑，並在潛在請求失敗時建立替代路由。有了 SureRoute，從CDN伺服器到源站伺服器的請求就不易發生您和 Akamai 無法控制的風險，例如網際網路通訊線路損壞或擁塞。

Akamai 會定期執行「競賽」，以判斷前往源站伺服器的最佳路由。競賽是由一般使用者對任何不可快取內容的要求觸發的。最終使用者收到內容後，SureRoute 會同時透過三個可用路由從邊緣伺服器轉發單獨的競爭請求到您的原始伺服器，以檢索特殊的 SureRoute 測試物件 （SRTO）。SureRoute 會記錄效能最佳的路由，並將其指定為未來請求的主要路由，直到下一場比賽進行。這些競賽使 SureRoute 能夠快速對互聯網的變化做出反應。您可以視需要配置競賽的頻率。 

引用原廠官方說明: kamai techdocs

簡單的說，Akamai會測試哪一條路可以比較快的抵達源站，這條路不一定是物理距離上最短的，單純就是看回應時間。但這個特性會有一個問題，每一次請求的路徑會因為競賽結果的調整有所不同，也就是如果你的請求不是同一筆時，可能會從另一台比較快的主機發出。

那expect: 100-continue的請求方式跟這機制有何關係呢?

「expect HTTP 標頭要求用途」-當請求端想要確保伺服器在傳輸訊息內文之前已準備好接收請求內容。例如，如果請求的內容非常大、不是伺服器接受的類型，或使用者未獲授權傳送檔案，則此處理程序可用來在傳送內容之前驗證這些條件。
收到 100 Continue 狀態碼之後，就可以傳送訊息本文。或者，如果伺服器傳回 417 預期失敗 HTTP 回應，則請求端不會繼續。
使用此方法的缺點是，由於 HTTP 要求標頭和本文是獨立傳送的，因此某些環境容易將它們分開，最終可能會傳回錯誤，而不是處理 HTTP 要求。

綜合上述的說法，因為CDN服務啟用Sureroute機制，當請求端以expect HTTP方式請求時，會因為請求標頭是獨立傳送的，所以當請求分別從不同CDN主機接收時，第二筆內容的請求會被CDN主機擋下。

畢竟第二筆請求對接收的主機會覺得奇怪，怎麼沒頭沒尾的就送內容要我轉傳!!

那現在怎麼辦!!

顧問回答，一個是關掉Sureroute機制，一個是請對方改請求的方式。

建議請廠商改，因為關掉Sureroute機制影響的是所有廠商，效能有差喔!!

開發單位也聽從顧問的建議，請廠商改掉就沒事了。

專案結束

隨著專案的推行，Jerry終於把所有服務導入CDN防護，也陸陸續續解決不少問題。

Jerry為了感謝顧問的辛勞，請顧問吃頓好的，順便慶個功。

兩人感嘆到，這個歷經半年的專案，感覺不只半年，天天渡日如年阿!!

Jerry更是不敢聽到電話打來，好像隨時服務又出了什麼問題，每天都心驚膽跳的!!

正當吃的開心的時候，機房又打來了!!

Jerry心想著，看來是不是該換工作了阿~~~~~~